|
Attributes can be categorized as:
|
|
|
Simple attributes
|
Carry simple data only. They may represent properties such as the material of a body or color of a face.
|
|
|
Complex attributes
|
Carry pointers to other entities. They may represent properties such as dimensions, constraints, or features.
ACIS constructs complex attribute structures to facilitate the extension of
ACIS to a specific product modeler.
|
|
|
Bridge attributes
|
Are used to link an
ENTITY with some application-specific, variable length data.
|
|
|
Instruction attributes
|
May be explicitly placed on entities to force certain behavior.
|
|
|
If an entity needs to reference some variable length data, an attribute is created to bridge (connect) from the entity to the data. The variable length data must be placed in an acceptable data structure (such as an array, linked list, or tree) and the attribute must contain a pointer to this variable length data (Figure 3-1).
|
|
|
|
|
Figure 3-1. Bridge Attribute
|
|
|
A
bridge attribute can be used to save and restore application-specific information. The functionality for saving and restoring lies in the
ENTITY class and is therefore inherited by classes derived from
ENTITY.
ATTRIB is derived from
ENTITY, so all classes derived from
ATTRIB inherit methods enabling them to be saved and restored. Application-specific information is probably not contained in objects derived from
ENTITY, so some means of bridging between the two sets of data (ACIS-specific and non-ACIS-specific data) is needed. Information that is related to an
ENTITY but not contained in the
ENTITY can be connected to the
ENTITY by putting an attribute on the
ENTITY. The attribute can either contain or point to the application-specific data.
|
|
|
A developer might use an attribute as a bridge to application-specific data when converting a subsystem into a separate system. For example, a developer might have originally created a subsystem with its own classes and structures, without intending it to be separate. If it is later decided to convert the subsystem into an independent system, rather than trying to fit the subsystem's classes and structures into the
ATTRIB format, the developer can retain the original classes and structures by defining an attribute as a bridge from
ACIS to the new system's data.
|
|
|
The methods of the attribute must save and restore and information; however, if the attribute merely points to the information is still responsible for causing the information to be saved and restored. If you put code in the
SAVE_DEF block of code for an attribute that saves the application-specific data, this code will be executed when the attribute is saved. Naturally, you must put code in the
RESTORE_DEF block of code to restore the same information that was written out in the
SAVE_DEF block. If you don't, you will get an error upon restoring the file containing the data.
|
|
|
The content and format of the saved data is up to the user. Obviously, other users will not be able to interpret the application-specific data in the file unless their applications also contain the user-defined attribute class definition.
|
|
|
Instruction attributes can be used to force one of several possible actions. For example, a blend on a face that runs into a sharp edge may be forced to roll on to that edge rather than to form a cap. The roll on instruction would actually be placed on the encountered edge.
|
|
|
Instructions may have positions associated with them to allow different behaviors at different points along the blended edge. In this case, the instruction nearest to the point of intercept applies.
|