Default Methods for Modeled Attributes
Modeled attributes will get 3 operations automatically from system generation. An example of an attribute named “cost”:
1. private void costValidate( String a_Cost ) throws WTPropertyVetoException
2. public void setCost( String a_Cost ) throws WTPropertyVetoException
• Calls the validate method before setting the attribute
3. public String getCost()
An example of an enumerated type attribute named “Material” with an aggregate association named “matl”:
1. private void matlValidate( Material a_Matl ) throws WTPropertyVetoException
2. public void setMatl( Material a_Matl ) throws WTPropertyVetoException
• Calls the validate method before setting the attribute
3. public Material getMatl()
Database Support
SQL scripts are generated when Database Support is selected.
The SQL scripts are generated into the WT_HOME/db/sql directory, nested in sub-directories that match the package structure of the customization in Rational Rose.
The location of WT_HOME/db/sql is actually controlled by a property wt.generation.sql.dir, with a target property file codebase/user.properties.
Table-specific SQL Artifacts
For each custom modeled class the following SQL scripts are generated:
• create_<CLASS_NAME>_Table.sql
– First drops the table “CLASS_NAME”
Note: This deletes data automatically, without prompting.
Make sure this is correct before executing the create_<CLASS_NAME>_Table.sql scripts.
– Creates the required table in the database.
– Must be run so that database indexes can subsequently be created.
• create_<CLASS_NAME>_Index.sql
– Creates indexes for performance or to maintain data integrity constraints.
– Must be run after creating tables, because indexes need to refer to table columns, and those columns need to already exist.
– Multiple indexes may be created for one table.
– Determination of indexes is made by the system generation logic.
• If additional indexes are needed, they can be created manually or by setting Windchill-specific properties in Rational Rose.
• For a custom attribute, this would be enabled by setting Index to True:
• drop_<CLASS_NAME>_Index.sql
– Must be run before dropping tables. Sometimes a table can not be dropped if there is an index against the table.
• drop_<CLASS_NAME>_Table.sql
– Must be run after dropping indexes.
Package-specific SQL Artifacts
For each package:
• Drop_pkg_<PACKAGE_NAME>_Table.sql / Drop_pkg_<PACKAGE_NAME>_Index.sql
– Calls all class-specific drop_<CLASS_NAME>_Table.sql /
drop_<CLASS_NAME>_Index.sql scripts in the current directory.
– Recursively calls Drop_pkg_*_Table.sql / Drop_pkg_*_Index.sql scripts in sub directories.
• Make_pkg_<PACKAGE_NAME>_Table.sql / Make_pkg_<PACKAGE_NAME>_Index.sql
– Calls all class-specific create_<CLASS_NAME>_Table.sql /
create_<CLASS_NAME>_Index.sql scripts in the current directory.
– Recursively calls Make_pkg_*_Table.sql / Make_pkg_*_Index.sql scripts in sub directories.
--
WT Introspector Support
• Updates registry properties
• Creates .ClassInfo.ser files
Localizable Displays
• Generates a localizable resource bundle file for basic modeled elements like class names and attribute names.
• Modeled elements have a Windchill property which specify if localizable resource bundles should be created during system generation.
Example of the Package Specification, Class Specification and Attribute Specification Windchill properties:
-=-=
The localizable resource bundle is located in the package and is named
<PACKAGE>ModelRB.rbInfo. It will contain the modeled elements that also specified “localizable=true”.
The following is an example of WT_HOME/src/com/customer/part/partModelRB.rbInfo where only the classes CustomerPart and Material specified “localizable=true”; none of the class attributes did:
CustomerPart.value=Customer Part
Material.value=Material
The following is an example of WT_HOME/src/com/customer/doc/docModelRB.rbInfo where the
classes CustomerOrder, ProductModel and the cost attribute specified “localizable=true”:
CustomerOrder.value=Customer Order
CustomerOrder.cost.value=Cost
ProductModel.value=Product Model
Modeled attributes will get 3 operations automatically from system generation. An example of an attribute named “cost”:
1. private void costValidate( String a_Cost ) throws WTPropertyVetoException
2. public void setCost( String a_Cost ) throws WTPropertyVetoException
• Calls the validate method before setting the attribute
3. public String getCost()
An example of an enumerated type attribute named “Material” with an aggregate association named “matl”:
1. private void matlValidate( Material a_Matl ) throws WTPropertyVetoException
2. public void setMatl( Material a_Matl ) throws WTPropertyVetoException
• Calls the validate method before setting the attribute
3. public Material getMatl()
Database Support
SQL scripts are generated when Database Support is selected.
The SQL scripts are generated into the WT_HOME/db/sql directory, nested in sub-directories that match the package structure of the customization in Rational Rose.
The location of WT_HOME/db/sql is actually controlled by a property wt.generation.sql.dir, with a target property file codebase/user.properties.
Table-specific SQL Artifacts
For each custom modeled class the following SQL scripts are generated:
• create_<CLASS_NAME>_Table.sql
– First drops the table “CLASS_NAME”
Note: This deletes data automatically, without prompting.
Make sure this is correct before executing the create_<CLASS_NAME>_Table.sql scripts.
– Creates the required table in the database.
– Must be run so that database indexes can subsequently be created.
• create_<CLASS_NAME>_Index.sql
– Creates indexes for performance or to maintain data integrity constraints.
– Must be run after creating tables, because indexes need to refer to table columns, and those columns need to already exist.
– Multiple indexes may be created for one table.
– Determination of indexes is made by the system generation logic.
• If additional indexes are needed, they can be created manually or by setting Windchill-specific properties in Rational Rose.
• For a custom attribute, this would be enabled by setting Index to True:
• drop_<CLASS_NAME>_Index.sql
– Must be run before dropping tables. Sometimes a table can not be dropped if there is an index against the table.
• drop_<CLASS_NAME>_Table.sql
– Must be run after dropping indexes.
Package-specific SQL Artifacts
For each package:
• Drop_pkg_<PACKAGE_NAME>_Table.sql / Drop_pkg_<PACKAGE_NAME>_Index.sql
– Calls all class-specific drop_<CLASS_NAME>_Table.sql /
drop_<CLASS_NAME>_Index.sql scripts in the current directory.
– Recursively calls Drop_pkg_*_Table.sql / Drop_pkg_*_Index.sql scripts in sub directories.
• Make_pkg_<PACKAGE_NAME>_Table.sql / Make_pkg_<PACKAGE_NAME>_Index.sql
– Calls all class-specific create_<CLASS_NAME>_Table.sql /
create_<CLASS_NAME>_Index.sql scripts in the current directory.
– Recursively calls Make_pkg_*_Table.sql / Make_pkg_*_Index.sql scripts in sub directories.
--
WT Introspector Support
• Updates registry properties
• Creates .ClassInfo.ser files
Localizable Displays
• Generates a localizable resource bundle file for basic modeled elements like class names and attribute names.
• Modeled elements have a Windchill property which specify if localizable resource bundles should be created during system generation.
Example of the Package Specification, Class Specification and Attribute Specification Windchill properties:
-=-=
The localizable resource bundle is located in the package and is named
<PACKAGE>ModelRB.rbInfo. It will contain the modeled elements that also specified “localizable=true”.
The following is an example of WT_HOME/src/com/customer/part/partModelRB.rbInfo where only the classes CustomerPart and Material specified “localizable=true”; none of the class attributes did:
CustomerPart.value=Customer Part
Material.value=Material
The following is an example of WT_HOME/src/com/customer/doc/docModelRB.rbInfo where the
classes CustomerOrder, ProductModel and the cost attribute specified “localizable=true”:
CustomerOrder.value=Customer Order
CustomerOrder.cost.value=Cost
ProductModel.value=Product Model