xxx9

Exercise 6-3: Clean up Previous Customization
Objectives
● Clean up previous customization.
Scenario
A model of a class previously created needs to be updated. Prior to making model changes,the previous customization needs to be considered and cleaned up. In this exercise, you will perform the required clean up operations against the previous customization so that the updated customization can proceed.
Step 1. Identify the table name associated with a class.
a. Open WTdesigner.mdl.
b. Open the properties for com.customer.CustomerOrder.
c. Select the Windchill tab.
Example:
d. CustomerOrder is a persisted class, since WTDocument was a persisted class. Therefore,CustomerOrder information must be stored in the database. There is a property in the model — TableName — that specifies the table name for a persisted class. The property is TableName property and it is set to <Use Class Name>, which means the name of the database table will be the same as the class name — CustomerOrder.
e. Why is WTDocument a persisted class?
Step 2. Interrogate the database regarding the custom class CustomerOrder.
a. How do you identify the Windchill database user name and password?
b. Log in to SQL*Plus as the Windchill database user.
c. Execute describe CustomerOrder.
d. What are the columns in this table?
Step 3. Interrogate the database regarding the custom class WTDocument.
a. CustomerOrder was extended from WTDocument. What are the columns in the WTDocument table?
b. The columns should be the same since CustomerOrder was extended from WTDocument with no other changes.
Step 4. Clean up previous customization.
a. When changing the model, developers should consider how the changes affect
previously-generated artifacts.
b. In the case of adding an attribute to a custom extension that is persisted, the attribute is stored in a row on a table.

System Generation
mData files are at the center of the system generation process, not the actual model
• This more easily allows for other modeling tools besides Rational Rose to be used for customizing Windchill
mData files are:
• Not a Rational Rose file
• Generated model data files that encapsulate information from the UML model
• Created during the first system generation and updated during subsequent system generation iterations
• Required for system generation of other outputs (e.g. Java and SQL code)
After system generation generates the mData files, the script WT_HOME/bin/JavaGen is executed. If the mData files are already present, JavaGen can be run from the command line to generate artifacts.
Note: Module Descriptor is a function reserved for R&D. Ignore it and do not select it.
Java Source
Java source files are generated when Java Source Code is selected.
The Java source is generated into the WT_HOME/src directory, nested in sub-directories that match the package structure of the customization in Rational Rose.
The location of Java source is controlled by a property wt.generation.source.dir, with a target property file codebase/user.properties.
Java source can be edited without worrying about future system generations overwriting the code as long as edits are made inside “preserve=true” blocks. The following example shows default preserve blocks for import statements, attribute definition, initialization, static initialization and operations:
//##begin user.imports preserve=yes
...
//##begin user.attributes preserve=yes
...
//##begin static.initialization preserve=yes
...
//##begin initialize%47E109400287.body preserve=yes
...
//##begin user.operations preserve=yes
...
Initialization Methods
The default initialization methods created inside the Java code do not fully initialize the object;
developers need to write the initialization logic.
Frequently, the super class initialization methods can be called to perform initialization. Examples:
Discussion question: since the custom initialization methods weren’t properly implemented, how did Windchill create instances of custom objects?
Note: It didn’t call un-implemented initialization methods or it did call Info*Engine.