3D PLM PPR Hub Open Gateway

Feature Modeler

Feature Modeler Overview

Essential characteristics, tasks and mechanisms of the feature modeler
Technical Article

Abstract

This article deals with the basic conceptual issues of the feature modeler.

The Characteristics of the Feature Modeler

The feature modeler has three main characteristics:

  1. It is a high-level object-oriented modeler in the sense that it allows the creation and management of simple or complex data objects
  2. It is a prototype/instance modeler because an instance can be modified so that it itself serves as a prototype for the creation of yet other instances.
  3. It is a spec/result modeler in that it allows the creation of a network of inter-related data objects in order to be able to automatically update the "result" of an object whose "spec" has been modified

[Top]

A High-Level Object-Oriented Data Modeler

Types of attributes.

A feature object can be partially described by its attributes. Attributes are like "slots" attached to feature objects in which data is stored. Attributes contain two main types of data:

  1. Simple data which is composed of single values of C++ types such as integer, double, string, etc.
  2. Feature data which is composed of a feature object which in turn has attributes that can be simple or feature types of data.

An attribute is essentially defined by its:

Let's look at a simple example. Say that we want to define a feature called "Point2D" which would represent a 2-D Point. This feature would have to reference at least the attributes containing the coordinates of a point. The feature object "Point2D.1" could look like this:

Note that the attributes "H" and "V" contain simple double-type values.

Let's define a second feature object, "Point2D.2":

Note that "Point2D.1" and "Point2D.2" have the same data structure: they are instances of the same feature type, "Point2D".

Now, we can define another feature object representing a line segment based on the two points defined above. "Line2D.1" would look like this:

Note that the "StartPoint" amd "EndPoint" attributes are feature-type attributes referencing "Point2D.1" and "Point2D.2".

Feature attributes are of two types:

  1. SpecObject or referenced. The feature can be referenced as an attribute by any number of other feature objects. It exists independently of the feature object to which it is attached.
  2. Component or aggregated. The feature can be aggregated by only one feature object to which it belongs henceforward. The aggregating feature object is said to be the parent of the aggregated feature object, called the child. If ever the parent is deleted, the child is also deleted. Once it has been aggregated, the existence of a child feature object is directly related to the existence of its parent.

Here is a complete schematic view of the different types of attributes:

Note that new attributes can be added to an existing feature object and that existing attribute values can be modified, thus allowing a feature object to be enriched dynamically at run-time.

An integrated modeler.

One major benefit of the data modeler aspect of the feature modeler is that it provides a set of generic mechanisms that are natively integrated to the V5 environment. In other words, each feature object created is treated as a native V5 object, thus benefiting from elaborate services existing automatically, which provide for the following tasks:

[Top]

A Prototype/Instance Object Model

About Prototypes

A feature prototype is a feature object. Any feature object is a potential prototype since it can be instantiated in order to create a new feature object. The initial feature prototype is called a StartUp and it is stored in a catalog to be accessed and re-used by any number of applications. It describes:

A StartUp may also have a supertype. In this case, it is said to "derive" from the StartUp having the supertype as its type. This means that it inherits not only the data structure of the deriving StartUp, i.e., its attributes, but any specific behavior it may have been given as well. Feature behavior is the set of operations that can be applied to a feature. These operations are, for example, the methods by which you can calculate values assigned to attributes.

Behind a feature late type, there are certain interface implementations specific to a given feature. In the previous example of the "Line2D" feature type, we saw that one of the operations needed to be applied to a line is to draw it: We would logically, therefore, have to define an interface containing a method by which the line can be drawn. Let's see what a complete prototype of the "Line2D" feature could look like:

Every feature of type "Line2D" instantiated from this prototype would inherit these same attributes and behaviors.

When a feature has been assigned a supertype, it can be manipulated by using the interfaces implemented both by its type and by its supertype. Here is another example of the "Pad" feature:

The "Pad" feature prototype has "Pad" as its type and "Prism" as its supertype. The "Prism" feature prototype has "Prism" as its type and "MechanicalFormFeature" as its supertype. You can manipulate a "Prism"- type feature with the interfaces implemented by both the types "Prism" and "MechanicalFormFeature". When you create a feature and specify a supertype for it, you are in effect extending both its behavior and its data. You extend the feature behavior as the feature receives an additional set of operations from the feature with the supertype as its type. You extend the data as the feature receives the attributes from the feature with the supertype as its type. In other words, you are deriving a new type of feature from an existing one.

In the above example, the feature "Prism" is defined by:

Having "Prism" as its supertype, "Pad", therefore, inherits the behaviors and attributes defined for the "MechanicalFormFeature" as well as the behavior and attributes defined for the "Prism".

[Top]

About Instances

A StartUp is retrieved from the catalog at run-time and it is instantiated in order to create a new feature object. When this happens, the StartUp is called the "reference" and the new feature object created is called the "instance". This new object inherits both the data structure, i.e., the attributes assigned to the StartUp, as well as the behavior attributed to it, i.e., the interfaces implemented for this feature type. You can see, then, how useful prototypes can be because they can be re-used, i.e., retrieved any number of times in order to create new feature objects from them.

An "instance", however, can also become a "reference" when it itself is instantiated to create another new feature object. In this case, the new "instance" created also inherits the actual values stored in the attribute "slots". The instance itself can be a reference. Actually, all feature objects are instances originally since all features are created by instantiation.

An instance is said to be strongly tied to its reference if few attributes of the reference have been overridden. It is said to be lightly tied to its reference if many attributes of the reference have been overridden.

When an instance is created from its reference, by default, the reference attributes are repeated in the instance. You can add new attributes to an instance and you can modify the value of an inherited attribute as well. When an attribute value is modified somewhere in the chain of the features depending on it, the modification is propagated to the objects downstream from the modified feature. However, at the same time, the modified feature has become distinct from its references upstream.

Above is an example of instantiation: Two new Point2D features, Point2D.1 and Point2D.2 are created. The first, Point2D.1, by instantiating the StartUp Point2D, the second by instantiating Point2D.1. Point2D.1 thus is both the instance of the Point2D reference and the reference of the Point2D.2 instance. If the attribute "H" were modified in Point2D.1, the change would be propagated to Point2D.2:

At the same time, Point2D.1 would become separate from its reference, Point2D, and any changes in the "H" attribute of Point2D would not be propagated to Point2D.1. However, if the initial value of V in Point2D were modified, this change would be propagated to Point2D.1 and Point2D.2.

As you can see, the Prototype/Instance Model allows for data extension through the instantiation mechanism (reference -> instance) and for behavior extension through the derivation of StartUps. In summary, it has the following characteristics:

Here is a schematic view of the prototype/instance mechanism:

[Top]

A Spec/Result Modeler

"Specs" are what make up an object, its definition. What happens after the "specs" have been processed is called the "Result". For example, in the case of a line segment:

Moreover, each point is specified by a set of coordinates:

The Spec/Result Modeler provides an infrastructure for spec/result management, also called the Build/Update mechanism.

Now, if ever any one of the coordinates of any one of the points were modified, the line segment would have to be redrawn as well. In other words, whenever the "specs" change, the "result" must be updated. As you can see, all of the results must be updated in order for the model to remain coherent. The Build/Update mechanism allows precisely for this to happen: Because of the inter-relations defined between specs, when one spec is modified, it automatically triggers the update of all of the specs dependent on it.

The Build/Update mechanism has two basic activities:

  1. Calculating each spec in order to update results. Whenever a spec input is no longer valid, a network of inter-related specs undertakes to re-calculate every dependent spec in turn in order to obtain an updated result.
  2. Defining the relationships between specs. The features defining these specs have a formal definition of their input/output attributes. They cooperate by forming a network in which the feature specs must produce a result given the valuated input values of the attributes.

Here is a general view of the update function of the Build/Update mechanism:

The main benefits of the Spec/Result Modeler are:

[Top]

Names of Features

For any StartUp or feature there are two kinds of names to consider, the internal name and the external name. The first is named "internal" because it is hidden for the end user. The "external" name is, on the other hand, seen through user interfaces, like the specification tree, and it is used for some user mechanisms such as the Search. 

Internal Name

For a StartUp, the internal name is its late type. When creating a StartUp, it is declared using the third argument of the CreateSUInCatalog method of the CATICatalog interface, or the second argument of the CATOsmSUFactory global function. Refer to the Other Entities section of the "CAA V5 C++ Naming Rules" article [10] for the StartUp (late type) naming rule. 

For a feature, the root of the internal name is given when instantiating the StartUp using the first argument of the Instanciate method, or if this value is NULL, it is the internal name of its StartUp. An index value can be appended to this root. See the Feature Indexation section for details. 

For both, it is not possible to change afterwards the internal name of a feature which is returned by the GetName of CATISpecObject. 

External Name

It is the name seen by the end user and which can be translated (NLS). With the difference of the internal name, it can be modified. The CATIAlias interface manages this name whith two methods whose specifications are the following:

CATIAlias Implementation

This interface manages the external name of a feature. This section explains the different Dassault Systemes (DS) implementations, and what do you need to do when you create your own feature.

Consequently, if your feature has no CATIAlias re-implementation in its inheritance to ensure the name persistency, the CATIAlias re-implementation is mandatory. On the other hand, if your feature derives from a DS feature, the re-implementation is not necessary, except for specific cases. The article entitled "Integrating New Features in CATIA" [12] explains how to re-implement CATIAlias and gives some recommendations.

Default External Name

For a StartUp, the default name is a name set in the CATNls file associated with the StartUp catalog - See the Naming StartUp section for implementation details. It is the recommended methodology. But if this Nls file is not provided, the second argument of the CreateSUInCatalog method is used as default, and if this method is not used it is the internal name of the StartUp which is used as default.

For a feature, its default name is the default name of its StartUp to which an index value can be appended, like for its internal name. See the Feature Indexation section for details. 

For both, the GetDisplayName method of  CATISpecObject interface returns the "default" external name of the feature.

Feature Indexation

As explained here-above, all instances of the same StartUp will have the same name (the default external name). It is often desirable to identify each instance with a unique name. This is achieved thanks to a mechanism known as Feature indexation, that adds an unique numerical suffix to the usual name: in a CATPart document, instances of the "Sketch" StartUp will be labeled "Sketch.1", "Sketch.2" and so on.

Names unicity directly depends on the suffix unicity. The numbers used as suffixes are granted by different sources that maintain a counter for each type of object requesting an index: the first "Line" will be "Line.1" and the first "Point" will be "Point.1". For each request the counter related to the requesting object type will be incremented and the new value will be attributed. Unicity only exist with respect to a source (also refered to as context).

  1. Default behavior.
    Feature indexation gets activated by default on a feature instance when this feature gets aggregated. In such a case the aggregating object (or "owner", or "father") will issue the new number to its component, making it's name unique among all the aggregating object components. This leads to a relative unicity: you cannot have two "Line.1" objects in the same Sketch object but a "Part/Sketch.1/Line.1" and a "Part/Sketch.2/Line.1" could exist in the same document. If this is not desirable see Customization section here-under. If the aggregation relation is suppressed (thanks to a call like CATISpecObject::RemoveComponent), the (ex)component will lose its suffix and its name will revert to the default external name. If aggregated again, the instance will get a new index from its new owner as if it had never been aggregated.

  2. Customized behavior.
    Indexation can also be used on root instances (i.e. instances that are not intended to be aggregated) via the CATISpecObject::SetAutoNameFather method. This will associate the instance and a numbering source as if the instance had been aggregated (hence the SetAutoNameFather method name). This operation is not reversible, and the index will not be changed if the instance gets aggregated. Only another call to SetAutoNameFather will alter the name if the index source is changed. The name will never revert to the default external name. This can be used to get a document wide name unicity by using the same context for all instances.

    If you plan to agregate features but still use a document-wide numbering, it is recommended to call the SetAutoName method before calling the CATISpecObject::SetSpecObject method or CATIDescendant interface to avoid wasting numbers and CPU cycles.

Limitations.

[Top]

The Basic Tasks Involved in Working with Features

Modeling StartUps

A StartUp is a feature prototype. It describes the preliminary data structure of a feature. To be meaningful, a StartUp definition should possess attributes. Attributes are the actual "slots" where feature data will be stored.

StartUps must be created in catalogs. A StartUp catalog is a special type of document which must be loaded into a session before any StartUp can be created or accessed. Creating StartUps in catalogs assures their persistency. It also allows existing StartUps to be shared by other applications.

The StartUp catalog file is a .CATfct file located in the CNext\resources\graphic directory of your framework.

[Top]

Accessing Catalogs

To create a new catalog, use the CreateCatalog global function which is exemplified in the CAAOsmCatalogSU use case [1]. 

Once features have been instantiated in a document, the catalog defining their StartUps cannot be re-created. You should only use the UpgradeCatalog [1] global function to modify the StartUp catalog. With this method you are in ReadWrite access mode on the catalog.
Once your catalog is ready for production usage you should distribute it in ReadOnly mode to avoid unwanted changes and its presence in the CATIA V5 "Save Management" command.

The AccessCatalog global function enables you to load a catalog in ReadOnly mode, it is sufficient to carry out instantiations, for example. 

The interface to manage a catalog is CATICatalog (ObjectSpecsModeler). This interface enables you:

Here is a table to summarize the StartUp catalog accesses:

Catalog Usage method / interface to use
Create CreateCatalog  
Update UpgradeCatalog 
Load AccessCatalog  
Manage CATICatalog  

[Top]

Creating a StartUp

Before studying in details the methods to create a StartUp, consider the various cases which can arise at you. For each case, there is an appropriate method:

All the three methods to create a StartUp are detailed below.

  1. The CreateSUInCatalog Method

    2. The new StartUp is created in the catalog using the CreateSUInCatalog method of the CATICatalog interface. It takes the following arguments:

    virtual HRESULT CreateSUInCatalog	(CATBaseUnknown** oStartUp,
                                         const CATUnicodeString* iName,
    			          const CATUnicodeString* iType,
    				 const char* iIntfName,
    			          const CATUnicodeString* iSuperType = NULL,
    				 CATBoolean iPublic=FALSE,
    				 CATBoolean iDerivable=FALSE) = 0;

    where:

    oStartUp can be directly cast to the requested interface pointer. In most cases, the CATISpecObject is the requested interface in order to add attributes to the new StartUp.

    To associate a NLS name to the StartUp and its instantiations, you should provide a CATNls file. If this file does not exist, iName, it is the default external name. Refer to the Names of Features section for details about the different names of a feature and Naming a StartUp for details about the Nls file. 

    The StartUp type must be unique within the catalog. 

    The StartUp supertype is the type of a previously defined StartUp, found within the same catalog or in a separate catalog that must, however, also be currently loaded into the session (The OpenPrereqCatalog should be used). Remember that a StartUp having a supertype means that it inherits attributes from the StartUp having the supertype as its type.

    The public state specifies if the StartUp can be added in a CATSpecs file [11] and the derivable state specifies if the StartUp can be the supertype of an another one. A derivable StartUp should be first public. 

    The CAAOsmCatalogSU use case [1] explains the creation of a StartUp from scratch and deriving from a StartUp in the same catalog. The CAAOsmExtDerivedSU use case [2] explains  the StartUp creation deriving from one which is defined in another catalog.

  2. The CATOsmSUFactory global function, the generic factory

    3. This generic factory is the CATOsmSUFactory global function. It takes the following arguments:

    HRESULT CATOsmSUFactory (CATISpecObject **opiNewStartUp,
    		       const CATUnicodeString *ipTypeName,
    		       CATICatalog *ipiClientCatalog,
                             const CATUnicodeString *ipSuperTypeName,
    		       const CATUnicodeString *ipCatalogName,
    		       const CATBoolean ipublicSU=FALSE,
    		       const CATBoolean iderivableSU=FALSE);

    where:

    It is almost the same arguments as the CreateSUInCatalog method. 

    Refer to the CAAOsmGenericDerivedSUFactory use case [8]

  3. A specific factory provided by the catalog's owner.

    4. For each StartUp of its catalog, the catalog's owner provides a global function to create a new StartUp deriving from its StartUp. This factory opens the catalog with OpenPrereqCatalog and uses CreateSUInCatalog to carry out the creation.

    Refer to the CAAOsmDerivedSUFactory use case [3]

[Top]

Adding Attributes to StartUps

In order to define the data structure of a new StartUp, it is necessary to describe its attributes. This is done using the AddAttribute method of the CATISpecObject interface. This method takes as arguments:

virtual CATISpecAttribute* AddAttribute	(const CATUnicodeString& iName,
                                                    CATAttrKind iType,
                                                    CATAttrInOut iFacet=sp_NEUTRAL )=0;

 

The attribute type describes the type of value the attribute can contain. Here is a complete list of the types of attributes that can be defined:

Type: Specifies:
tk_string C++ char * type
tk_double C++ double type
tk_boolean CATBoolean type
tk_octet C++ unsigned char type
tk_integer C++ integer type
tk_specobject "referenced" feature attribute
tk_component "aggregated" feature attribute
tk_external symbolic link to another feature object
tk_list list of any other type

An attribute can have a given type and tk_list at the same time. For example, it can be a tk_string and a tk_list, meaning that it contains a list of string-type data.

The tk_specobject and tk_component attribute types define particular feature attributes. In other words, the attribute data will contain a pointer to another existing feature. The difference between attributes of type tk_specobject and those of type tk_component is that in the former case, the feature data structure pointed to by the attribute is said to be "referenced" by it and in the latter case, it is said to be "aggregated" to it. A "referenced feature" can be referenced by any number of other features. It exists independently of any of them. On the contrary, an "aggregated feature" belongs to the feature that aggregates it. It cannot belong to any other feature and its existence is tied to this "parent" feature.

Here is a schematic view of attribute types and their possible type-definitions:

See the CAAOsmCatalogSU use case [1] for a complete programming example showing how to add attributes to StartUps.

[Top]

Naming a StartUp

The Names of Features section of this article explains the difference between the internal name of a StartUp ( its late type) and the external name. It is strongly recommended to provide the default external name (if no end user name) by a NLS file. If you provide this file, the name returned by the GetDisplayName method will be the value set in this file. It can be also returned by the CATIAlias interface, but it depends on its implementation on the StartUp. 

There is a .CATNls file corresponding to each .CATfct catalog.  The .CATNls file is a normal text file. Its name must be the same as the catalog name + "NLS" and the .CATNls suffix. The file is delivered in the CNext + resources + msgcatalog directory of your framework. The contents of the file must follow a precise format: for each feature name that is displayed to the user, a text line must be created containing the correspondence FeatureInternalName = "NLS Name" .

Here is an extract of the English CAAOsmCatalogSUNLS.CATNls file [1]:

CAAOsmPublisher="Publisher";

where CAAOsmPublisher is the internal name of a StartUp creating by the CAAOsmCatalogSU use case [1]. 

[Top]

Modeling Features

Instantiating StartUps and Features

Once a StartUp exists in a catalog, it can be retrieved in order to create a new feature. This is done using the RetrieveSU method of CATICatalog. This method takes the following arguments:

virtual HRESULT RetrieveSU	(CATBaseUnknown** oStartUp,
		          const CATUnicodeString* iType,
			 const char* iIntfName) = 0;

 

The resulting CATBaseUnknown pointer, oStartUp, can be directly cast to requested interface pointer,iIntfName.

Now that the StartUp has been retrieved, it can be instantiated in order to create a new feature object. This is done using the Instanciate method on the CATISpecObject pointer to the StartUp. This method takes the following arguments:

virtual CATISpecObject* Instanciate(const CATUnicodeString& iName = NULL_string, 
				 const CATIContainer_var& iContainer = NULL_var, 
				 CATBoolean iNeedToSave = FALSE) = 0;

 

The new feature itself, once created, can be instantiated in order to create yet another new feature using the same Instanciate method on the CATISpecObject pointer to the feature object itself.

The data of any new feature object created can be extended as compared to the initial StartUp data structure by simply adding new attributes to it.

See the CAAOsmSimpleAttr use case [4] for an example showing how new features are created through instantiation.

[Top]

Valuating Attributes

A feature definition becomes meaningful only when its attributes are actually valuated. In order to do this, it is necessary to access the attribute key for each attribute to be valuated using the GetAttrKey method of CATISpecAttrKey on the name of the attribute. Then, use any of the Set... methods of CATISpecAttrKey passing the key itself as an argument in order to valuate an attribute.

See the CAAOsmSimpleAttr use case [4] for an example showing how simple attributes are valuated.

See the CAAOsmReferencedAttr use case [5] for an example showing how referenced attributes are valuated.

See the CAAOsmAggregatedAttr use case [6] for an example showing how aggregated attributes are valuated.

[Top]

Retrieving Attributes

In order to retrieve the attribute values of a feature object, it is necessary to access the attribute key for each attribute to be retrieved using the GetAttrKey method of CATISpecAttrKey on the name of the attribute. Then, use any of the Get... methods of CATISpecAttrKey passing the key itself as an argument in order to retrieve the value of the an attribute.

See the CAAOsmSimpleAttr use case [4] for an example showing how simple attributes are retrieved.

See the CAAOsmReferencedAttr use case [5] for an example showing how referenced attributes are retrieved.

See the CAAOsmAggregatedAttr use case [6] for an example showing how aggregated attributes are retrieved.

[Top]

Extending a Feature

A feature object can be enriched by adding one or several extensions on it.

See the referenced article CAAOsmHowToAddDataToAFeature [7] showing how feature objects can be extended.

[Top]

Deleting a Feature

In order to delete a feature, simply get a LifeCycleObject handle on it and to use the remove method.

See the CAAOsmReferencedAttr use case [5] for an example showing how feature objects can be deleted.

[Top]

 

The Build/Update Mechanism of the Specs/Result Modeler

The objective of the Specs/Result Modeler is to offer a general model for the definition and management of specs and results, to be able to particularize this model, and to manage common mechanisms automatically. The Build/Update Mechanism is the means of reaching this objective.

[Top]

Building a Feature

As you have seen in the previous sections, a feature is an object to which attributes are assigned. These attributes are usually related to each other. The values of certain attributes result from an operation taking as its input parameters the values of other attributes.

For a given feature, the Build operation consists in defining how certain attributes depend on others and how to recalculate the value of attributes so that all the attributes of a feature have consistent values.

A Build operation may use as its parameters values originating from other features. Suppose you have just performed a Build operation on a feature and somewhere among all the features and feature attributes upstream, something is modified. This may have an impact on your feature. Your feature may require a parameter which is a value resulting from another feature which itself uses as a parameter an attribute just modified. In such a case, your first feature is in an inconsistent state. To make your feature consistent, you should normally detect what has been modified upstream from your feature, then rebuild one by one all the features that need to be rebuilt upstream up to your first feature, i.e., the one you want to make consistent. This would be quite a chore and a risky one as you will never be able to guarantee that you have not missed something. To avoid this problem, the feature platform provides you with an algorithm which, when applied to a given feature, detects and rebuilds what is necessary to make the feature consistent.

Every time this mechanism is applied to a feature, all the features upstream from the updated feature are rebuilt if needed, i.e., if they are found to be out of date by the mechanism.

This default algorithm is based on the sp_IN and sp_OUT qualities of the attributes which are analyzed by the Update operation. The attribute quality is passed as the last argument of the CATISpecObject::AddAttribute method when the attribute is initially defined. The possible values are:

See the CAAOsmCatalogSU use case [1] for an example of the AddAttribute operation with "sp_" qualities.

How you choose the quality of an attribute depends on how you want each attribute and feature of your application to be updated when one of the objects potentially impacting other objects of your feature network is modified. The default Update algorithm operates according to the attribute qualities. If you use this default Update mechanism, the trick is then to specify the appropriate qualities for attributes.

Attributes defined with sp_IN are those which are usually required to define or specify a feature. If one of these values is modified, you wish to rebuild your feature when it is applied the Update command. These attributes are all recognized by the default Update operation. When the default Update operation is applied to a feature, the Build/Update mechanism automatically scans all the sp_IN attributes of all the features potentially impacting the feature to be updated to detect whether any of these attributes has been modified.

Attributes defined with sp_OUT are those whose values result from a Build operation and may be used as input parameters for other features. The Update algorithm needs to determine whether these attributes are up-to-date and if they are not, how they can be updated. Specifying an attribute as sp_OUT means that the attribute is not up-to-date if its owner feature is not up-to-date. In order to update the sp_OUT attribute, you must first update its owning feature.

Attributes defined with sp_NEUTRAL are ignored by the default Update operation.

[Top]

Updating a System of Features

Let's again take the example of the line segment defined by two points. For each point, a Build operation is defined in order to re-draw the point using the modified value of one or more of its coordinates. Whenever a modification occurs, an Update operation on the Line is performed, triggering the Build operation to be executed on the Point whose value has changed. A Line will also have a Build operation associated with it so that it can be re-drawn whenever one of its values has changed. Here is the order in which the Update of the line will occur:

Now, in order for the "Build Point2D.1" operation to occur, the keyword sp_IN must have been added to the attribute "StartPoint" of the "Line2D" feature. This means that this value must be valid before the building of the line can occur. So, the building of "Point2D.1" is performed, unless it is known to be valid already. The same goes for the attribute "EndPoint" and for "Point2D.2". The "H" and "V" attributes of the "Point2D" feature, however, must be declared as sp_IN.

The specific Build operation is defined by implementing the CATIBuild interface. The default Build operation is empty. There is, however, a default Update operation, triggered by the execution of the Update method of CATISpecObject.

See the CAAOsmBuildUpdate use case [9] for a complete programming example of the Build/Update Mechanism.

[Top]

Summary of Essential Tasks

Method Name: Interface Name: Function:
AccessCatalog global Loads an existing catalog into the current session in Read Only mode.
CreateCatalog global Creates a new catalog.
CreateSUInCatalog CATICatalog Creates a new StartUp in a given catalog.
GetAttrKey CATISpecAttrKey Retrieves the attribute key of a given attribute for a feature object.
GetInteger, GetString, Get... CATISpecAttrKey Retrieves the value of an attribute.
Instanciate CATISpecObject Instantiates a StartUp (or feature object) in order to create a new feature object.
OpenPrereqCatalog CATICatalog Loads an existing catalog containing a StartUp from which the client wants to derive a new StartUp in yet another catalog.
remove LifeCycleObject Deletes a feature object.
RetrieveSU CATICatalog Retrieves an existing StartUp from a catalog.
SetInteger, SetString, Set... CATISpecAttrKey Valuates an attribute.
UpgradeCatalog global Loads an existing catalog into the current session in Read/Write mode.

[Top]

In Short

The Feature Modeler is a high-level object-oriented data modeler, a prototype/instance object modeler and a spec/result modeler.

The basic tasks required when working with features deal with creating StartUps in catalogs and with modeling actual feature objects. New catalogs can be created or existing catalogs can be loaded into the current session. Once a catalog exists in the session, working with StartUps consists in creating them, accessing them, or adding new attributes to them. New feature objects are created in a document by the instantiation of an existing StartUp or of another feature object. Working with a feature object consists in valuating its attributes, retrieving its attributes and deleting the feature object itself.

The Build/Update Mechanism consists in defining Build operations for specific features that are implicated in an inter-related system of specs and results. The execution of an Update operation triggers the different Build operations to be performed in order for the system to yield coherent results.

[Top]

References

[1] Creating StartUps in Catalogs
[2] Creating an Externally Derived StartUp
[3] Deriving New StartUps Using Provided Factories
[4] Working with Features
[5] Referencing Features by Features
[6] Aggregating Features to Features
[7] How to add data to a feature
[8] Deriving New StartUps Using a Generic Factory
[9] The Build/Update Mechanism
[10] CAA V5 C++ Naming Rules
[11] Managing Public Features and Attributes
[12] Integrating New Features in CATIA 
[Top]

History

Version: 1 [Aug 2000] Document created
Version: 2 [Jun 2003] StartUp and Feature names
Version: 3 [Jul 2004] Clean up
Version: 4 [Nov 2004] Extensions
[Top]

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